Various forms of network-based storage systems exist today. These forms include network attached storage (NAS), storage area networks (SAN's), and others. Network-based storage systems are commonly used for a variety of purposes, such as providing multiple users with access to shared data, backing up critical data (e.g., by data mirroring), etc.
A network-based storage system typically includes at least one storage server, which is a processing system configured to store and retrieve data on behalf of one or more client processing systems (clients). The data is stored and retrieved as storage objects, such as blocks and/or files. A block is a sequence of bytes or bits of data having a predetermined length. A file is a collection of related bytes or bits having an arbitrary length. In the context of NAS, a storage server operates on behalf of one or more clients to store and manage file-level access to data. The files may be stored in a storage system that includes one or more arrays of mass storage devices, such as magnetic or optical disks or tapes, by using a data storage scheme such as Redundant Array of Inexpensive Disks (RAID). In a SAN context, a storage server provides clients with block-level access to stored data, rather than file-level access. Some storage servers are capable of providing clients with both file-level access and block-level access, such as certain storage servers made by NetApp, Inc. (NetApp®) of Sunnyvale, Calif.
Requirements associated with the data stored in network-based storage systems relating to expected performance, reliability, etc. are collectively referred to as service-level objectives. Service-level objectives may be specified and managed by an administrator, administrative tool, or both. The number of infrastructure layers managing a storage system has increased significantly over time. Exemplary layers that may have a role in managing a storage system include a storage system layer, network layer, hypervisor layer, cache layer, etc. As a result of this increase in infrastructure layers, performance and reliability of the storage system now depend upon different infrastructure layers. For example, the different infrastructure layers are managed by different people or tools, making it hard to derive unified performance guarantees such as service-level objectives. A variety of techniques are emerging to dynamically tackle changes in workloads, changes in service-level requirements, etc. for individual infrastructure layers. Exemplary techniques include tools that make changes to storage data layouts, dynamically instantiate resources for caching, perform volume migration, perform Logical Interface (LIF) migration, etc. These techniques, however, do not provide an end-to-end approach for storage management that interacts with and manages all infrastructure layers. When multiple tools work independently, they may expend more resources than needed to address a service-level objective and risk the possibility that the tools will counteract each other's efforts, cause an error/unavailability, or cause another service-level objective violation.
For example, data migration can be performed at different infrastructure layers (storage-level, hypervisor-level, etc.) to handle service-level objective violations. Two independent tools may react to the same service-level objective and, unaware of one another, attempt to migrate the same data to different locations. Alternatively, if the two independent tools are concerned with two different sets of data on the same resource, both independent tools may determine that their respective service-level objectives would be met if they were dealing with a less congested resource. Unaware of one another, both independent tools may seek similar corrective solutions by each migrating their own set of data from the first resource to a second resource. More time and effort has been expended in each tool performing data migration as compared to only one tool taking corrective action. Additionally, the independence of the tools carries the risk that both tools have migrated their data to the same second resource and gained no advantage: the second resource is congested rather than the first resource and the respective service-level objectives are still unmet.